Map projections have been used to convert geographic database source information into a rectangular coordinate system to build a run-time visual environment database that can be processed and displayed by a computer image generator. The methods used in these projections have developed over the years to accommodate and correct for most (but not all) of the distortions introduced by the map projection. In the end, the conversion method is complex and there are still potentially observable problems in geodetic databases because of these distortions. There has always been a need and a desire to create a coordinate system and a technique for creating and rendering the databases that would correlate precisely to the real world over any area of the world. Unfortunately, the precise correlation has been difficult to provide because of the incongruities between spherical and rectangular coordinate systems. Further, rectangular coordinates are needed by image generators, and so complex conversions have been used between spherical and rectangular coordinates.
At least two different coordinate systems will be used in this description to describe the position of an object on or near the earth. Two of these coordinate systems are the geodetic and topocentric systems. Each of these coordinate systems will be described below.
Geodetic Coordinates are typically used when describing the position of an object on the surface of the earth or an object in the air that is not too far from the surface. FIG. 1 illustrates latitude 100, longitude 102 and the equator 104 on the earth. The geodetic coordinate system uses the references of latitude (φ), longitude (λ), and altitude (h). This system of geodetic coordinates is well known and commonly used for navigational purposes. In addition, FIG. 2 illustrates an ellipsoid 110 that represents the earth and for a given point P
As discussed, the problem with geodetic coordinates in an image generator database is that geodetic coordinates are spherical in nature and the image generator needs to work with rectangular or Cartesian coordinates. The geographic source material that is typically used to generate a database comes in geodetic coordinates, but the actual primitives manipulated by the image generator are in rectangular coordinates using (x, y, z). Consequently, there is the need for some type of a transformation from geodetic to rectangular coordinates. In the context of the present discussion, it is valuable to describe topocentric coordinates that are eyepoint centered. The origin of topocentric coordinates is at the current latitude and longitude of the eyepoint with the altitude set to 0 at mean sea-level. If the eyepoint is at a current position of (φ0, λ0, ho0), then the origin of the topocentric coordinate system is (φ0, λ0, 0).
FIG. 3 illustrates a distant perspective on the topocentric coordinate system where the coordinate axes are oriented so that the +Y axis points true north 120, the +X axis points due east 122, and the +Z axis is oriented straight up 124. The XY plane of the coordinate system is defined to be tangent to the earth model ellipsoid at the eyepoint with the +Z axis being normal to the XY plane at the origin. FIG. 4 is a closer view of a topocentric coordinate system.
Using topocentric coordinates along with a projection process is roughly equivalent to placing a flat plane (representing the needed database area) tangent to the surface of the earth with the plane's center touching the earth. Then the terrain and features are projected from the earth onto this plane. As the plane size is increased, the distortion at the plane's edges will increase. Thus, for databases larger than several hundred miles radius, several tangent planes can be used with their own projection spaces to reduce the distortion. Then the simulation system must manage the problem of crossing from one plane to the other at run time. This involves solving the geometric mismatch of the terrain and features across these boundaries, and hiding cracks caused by the lack of strict vertex sharing.
In other cases, where a very long (but not very wide) geographic database is required, a tangent cylinder can be used. In each case, the transforms that preserve directions and scales are defined as accurately as possible. Usually, this involves a continuous distortion of positional information supplied by a host program in order to derive the position and orientation of the instantaneous eyepoint in the tangent plane or cylinder.
The visual manifestation of increasing distortions on the plane is that simulated objects do not appear to be the correct distance apart. For example, if the simulation is a flight simulator, then the distortions will affect the laser range finders; or in certain directions the distortion will affect the sensors and magnified channel targeting functions. In extreme cases, scale distortions begin to cause a perceptible difference between indicated and observed velocity of the eyepoint or vehicle.
The source material used to construct the visual environment databases typically includes a terrain elevation grid that is regular and orthogonal in latitude/longitude (lat/long). For example, DMA DTED (Defense Mapping Agency—Digital Terrain Elevation Data), and other vector feature data, such as DMA DFAD (Defense Mapping Agency—Digital Feature Analysis Data) can be used which are also in lat/long coordinates. Various database library models of individual scene features, such as buildings and landmarks, are constructed and stored in the database in Cartesian coordinates.
All of the data that starts in lat/long is typically re-sampled into the chosen Cartesian system. In other words, the geographic data is projected from the spherical earth onto the chosen tangent plane. This operation is unique and specific to the particular choice of a tangent plane, so the resulting data is useful only for a particular customer and project using this plane. Any subsequent operations on the data, including error correction, updating, and enhancements are specific to a given customer and cannot easily be used in generic situations. Any image data or textures that are applied to the terrain must be re-sampled with this projection and become project-specific. Since these transformations are done early in the compilation of the database, the volume of data is large and the computation takes a significant amount of CPU time.
The existence of projections has many ripple effects and ultimately influences other parts of the simulation environment. For example, customers may want to be able to correlate the database with paper maps and charts. In order to make this work properly, the creator of the database generally ends up creating these charts from the final database, so that the transforms and projections applied in making the database are properly accounted for. Thus, distances measured directly on the charts correspond to distances in the tangent plane, etc.
Another side effect of the projections affects the modeling tools. Modelers have an ongoing need to create and revise features, buildings, and landmarks whose position is derived from lat/long sources. This means that customer-specific projections have to be supported or at least accounted for in some of the modeling tools, including some interactive, visual editors. All of these project specific modifications create a tremendous amount of work to create just one run-time visual environment database.